當你把產品包裝好之後, 要怎麼銷售出去呢？

『銷售』套用在系統開發上面就是怎麼讓外部的系統能夠使用到自己開發好的功能, 我們會把開放功能的方式稱作開API接口。API接口就像是到麥當勞點餐時幫忙服務的櫃檯人員, 消費者告訴櫃檯要點什麼餐, 櫃檯再依照餐點內容逐一核對細項並過濾掉非銷售的商品, 統整好內容再傳達給負責的人員, 等到負責人員回覆餐點之後再由櫃檯人員傳遞給客人, 這就是一個API溝通的過程。

目前處理過的API提供方式有RESTful API 跟 gRPC API, 大致上會用對內跟對外來區分要採用哪個, RESTFUL API 主要用在跟外部廠商溝通使用, gRPC API則是內部專案溝通使用。

gRPC vs HTTP API簡介

• gRPC

  gRPC 使用 Protobuf 序列化進行資料傳輸, 走的是RPC協定, 因為傳輸的資料切分的很小, 傳輸的速度很快, 是目前我們主要使用的溝通方式, 它無法被瀏覽器呼叫到, 但可以安裝gRPCurl來測試。
  使用gRPC時, Client端也要有一份proto才能正確打到服務, 服務也必須依照proto制定的格式來接收跟傳送, 由於雙方都是以proto做依據, 所以只要制定好proto之後, Client端就可以同步進行API介接, 這樣不只縮短了開發過程中來來回回確認格式的狀況, 也減少了介接API時發生圖文不符的狀況。缺點是每次異動proto之後, 如果client 端需要使用到新的spec內容就必須更新一次proto, 這也是為什麼他不適合用在跟外部廠商溝通。

• HTTP

  HTTP API 是依照RESTful規範設計的API, 走的是HTTP協定, 它可以透過瀏覽器打到API, 是最常見的API設計。它適用在團隊之外的溝通方式, 大多數的語言都有支持RESTful API, 只要server修改格式之後, client不需要更新其他項目就可以拿到新的API內容, 它的傳輸格式都是由工程師透過文件說明的, 由於它不像gRPC要符合spec才可以正確的輸出跟取得資料, 相較之下容易發生API圖文不符的狀況。

本次模擬會以gRPC API來開發, gRPC接口也可以透過一些手法同時實作出http接口, 例如使用grpc-gateway或自行包裝http router 轉換到grpc實作接口也可以, 它可以同時提供兩種類型來滿足不同的需求。